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(57) Abstract 

An Application Programming 
Interface (API) far applications to 
manage/access user-related information 
on a Digital Television (DTV) 
Receiver/Terminal. The API provides 
a multi-user environment (using user 
registry (210) and user profile (220) 
classes), and a registry for preferences 
(310) which can be associated with 
an individual user (user-specific) or be 
common to all users (system-wide). A 
set of permissions (230) is associated 
with each user, or at least with a default 
user, which represents anybody watching 
the TV. The permission may provide, 
for example, a parental control/rating 
ceiling or permission to buy Impulse 
Pay Pct View (IPPV) programs, or 
engage in e-commerce transactions 

(e.g., purchase goods or services via the television). The invention also supports a mechanism (220) where some applications can, and 
some cannot, access the preferences based on a security policy. This means that the user may allow only specified trusted applications to 
access his/her credit card number but not others, for example, for an e-commerce application. 



130 




FOR THE PURPOSES OF INFORMATION ONLY 
Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCX 



AL 


Albania 


ES 


Spain 


LS 


Lesotho 


SI 


Slovenia 


AM 


Armenia 


FI 


Finland 


LT 


Lithuania 


SK 


Slovakia 


AT 


Austria 


FR 


France 


LU 


LuACfnbourg 


SN 


Senegal 


AU 


Australia 


GA 


Gabon 


LV 


Latvia 


SZ 


Swaziland 


AZ 


Azerbaijan 


GB 


United Kingdom 


MC 


Monaco 


TD 


Chad 


BA 


Bosnia and Herzegovina 


GE 


Georgia 


MD 


Republic of Moldova 


TC 


Togo 


BB 


Barbados 


GH 


Ghana 


MC 


Madagascar 


TJ 


Tajikistan 


BE 


Belgium 


GN 


Guinea 


MK 


The former Yugoslav 


TM 


Turkmenistan 


BP 


Burkina Faso 


GR 


Greece 




Republic of Macedonia 


TR 


Turkey 


BG 


Bulgaria 


HU 


Hungary 


ML 


Mali 


TT 


Trinidad and Tobago 


BJ 


Benin 


IE 


Ireland 


MN 


Mongotia 


UA 


Ukraine 


BR 


Brazil 


IL 


Israel 


MR 


Mauritania 


uc 


Uganda 


BY 


Belarus 


IS 


Iceland 


MW 


Malawi 


us 


United States of America 


CA 


Canada 


IT 


Italy 


MX 


Mexico 


uz 


Uzbekistan 


CF 


Central African Republic 


JP 


Japan 


NE 


Niger 


VN 


Viet Nam 


CG 


Congo 


KB 


Kenya 


NL 


Netherlands 


YU 


Yugoslavia 


CH 


Switzerland 


KG 


Kyrgyzstan 


NO 


Norway 


ZW 


Zimbabwe 


a 


Cote d'lvoixc 


KP 


Democratic People' • 


NZ 


New Zealand 






CM 


Cameroon 




Republic of Korea 


PL 


Poland 






CN 


China 


KR 


Republic of Korea 


FT 


Portugal 






CU 


Cuba 


KZ 


Kaxakstan 


RO 


Romania 






CZ 


Czech Republic 


LC 


Saint Lucia 


RU 


Russian Federation 






OE 


Germany 


LI 


Liechtenstein 


SD 


Sudan 






OK 


Denmark 


LK 


Sri Lanka 


SB 


Sweden 






EE 


Estonia 


LR 


Liberia 


SG 


Singapore 







Description 



5 



10 



15 



20 



25 



30 



35 



40 



45 



55 



WO 00/30345 



PCT/US99/23346 



20 



10 

DIGITAL TELEVISION RECEIVER WITH APPLICATION PROGRAMMING INTERFACE FOR USER MANAGEMENT 
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BACKGROUND OF THE INVENTION 

5 This application claims the benefit of U.S. 

Provisional Application No. 60/107,949, filed November 
12, 1998. 

The present invention provides an Application 

Programming Interface (API) for downloadable broadcast 

25 . . , . . , . _ 

iu applications co manage/access user-reiacea mrormation 

on a Digital Television (DTV) Receiver/Terminal. 

A set-top terminal, also referred to as an 
Integrated Receiver-Decoder (IRD) or a subscriber 
terminal , is a device that receives and decodes 
15 television signals for presentation by a television. 

The signals can be delivered over a satellite, through 
a cable plant, or by means of terrestrial broadcast, 
for example. Various applications have been proposed, 
or are currently available, via modern set tops, 
20 including video on demand (VOD) , audio on demand, pay- 

per-view, interactive shopping, electronic commerce, 
40 electronic program guides, Internet browsers, mail 

services (e.g., text e-mail, voice mail, audio mail, 
and/or video mail) , telephony services, stock ticker, 
25 weather data, travel information, games, gambling, 
45 banking, shopping, voting, and others. Applications 

may also enable Internet connectivity and possibly 
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Internet-based telephony. The set top functionality is 
enabled through specialized hardware and software. 

The applications may be downloaded by terminals 
via a network, loaded locally (e.g., via a smart card), 
or installed at the time of manufacture, for example. 

Moreover, with the increasing integration of 
computer networks such as the Internet, telephony 
networks, and broadband distribution networks, many 
opportunities arise for providing new types of 
applications. 

To optimize the user's ability to access these 
applications, there is a need for user management at 
the terminals. In particular, it would be desirable to 
provide a user -management API that can be implemented 
in software independently of a terminal's hardware and 
operating system. 

The API should allow new users to be recognized, 
or old users to be deleted, as well as recognizing a 
current user of the terminal. The API should provide a 
profile of the each user and maintain a record of 
permissions that have been granted to the users, e.g., 
for accessing applications such as pay-per-view, or 
enforcing rating guidelines for children. 

The API should maintain a record of user 
preferences, such as preferred language and rating 
ceilings, personal data such as age, address, zip code, 
account numbers, as well as system-wide preferences, 
such as favorite channels, language, etc. 

The API should also maintain a registry of 
applications, resources, preferences and users. An 
application may use/access a resource, which is usually 
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a device, function or a process on the receiver (e.g. 
tuner, modem, database, etc.) 

The API should be compatible with Java(tm), 
ActiveX (tm) or an equivalent type of component based 
object-oriented technology. 

The API should be compatible with Digital Audio 
Visual Council (DAVIC) , American Television Standards 
Committee (ATSC) T3/S17 Digital TV Application Software 
Environment (DASE) , Digital Video Broadcast (DVB) - 
Mult i -Media Home Platform (MHP) and other related 
environments . 

The API should be compatible with any application 
at a terminal, regardless of how the application was 
received or installed (e.g., downloaded, resident, from 
smart card, etc.) 

The present invention provides a system having the 
above and other advantages. 
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SUMMARY OF THE INVENTION 



The present invention provides a software 
architecture a set-top television terminal. In 
particular, an Application Programming Interface (API) 
is provided for applications to manage/access user- 
related information on the terminal. 

A "user" is one who is watching the TV or using 
its other functions, e.g., E-mail, games, etc. 

The API includes a user software package that 
includes registry, profile, permissions, change cause, 
change event, and registry event functions. A 
preferences package includes a registry, names, rating, 
preferred language, change cause, change event and 
registry event functions. A registry package includes 
type, factory, change event, listener, user, 
preference, resource and application functions. 

The present invention provides a multi-user 
environment (user registry and user profile) , and a 
registry for preferences which can be associated with 
an individual user (user-specific) or be common to all 
users (system-wide) . A set of permissions is 
associated with each user, or at least with a default 
user, which represents anybody watching the TV. 

In a particular embodiment, a television set-top 
terminal includes a computer readable medium having 
computer program code means, and means for executing 
the computer program code means to implement an 
Application Programming Interface (API) . The API 
provides (a) a user registry of a plurality of users of 
the terminal, (b) a preferences registry of preferences 
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of the users, and (c) permission (s) for controlling the 
users' access to at least one application that is 
provided at the terminal. 

The API provides a security policy to allow only 
5 specified applications to access the preferences 

registry. The security policy may be user-controlled. 
Thus, some applications can, and some cannot, access 
the preferences based on a security policy. This means 
that the user may allow only specified trusted 
10 applications to access his/her credit card number but 
not others, for example. These applications may be 
specified shop-at-home channels or the like. 

The API disallows access to user preferences by an 
application that does not have the required 
15 permission (s) . 

The permission (s) may be associated with each user 
individually, or may be associated with a default user. 
A default user might be provided to indicate that the 
entire family is watching the television together, or 
20 to indicate a guest or unknown person. 

Additionally, the application generally is 
responsive to the user preferences. For example, if an 
application such as an Electronic Program Guide (EPG) 
accesses a language preference of a particular user, 
40 25 the application can automatically select the language 

for text when the service information (SI) is 
multilingual. An application that tunes to channels 
(audio/video or audio-only) may automatically select 
the appropriate audio language based on the user's 
30 language preference. 

As another example, an EPG application may access 
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favorite channel information of a user to prepare a 
custom made guide to the programs that are currently 
playing. Or, an application which enables targeted 
advertisements may access information regarding a 
user's location (ZIP code), gender, age, family status, 
and other personal information, such as pets, hobbies, 
etc . 

Additionally, e- commerce -type applications may 
need to look at user credit card numbers, permissions 
to do on-line purchases, and other related preferences. 

The permission may also provide, for example, a 
parental control/rating ceiling or permission to buy 
Impulse Pay Per View (IPPV) programs, or engage in e- 
commerce transactions (e.g., purchase goods or services 
15 via the television - home shopping) . 

The preferences include a ratings ceiling 
preference. 

Moreover, the user preferences may include system- 
wide or user-specific. 

The user registry can be used to register a new 
user of the terminal, identify a current user of the 
terminal, and remove a former user of the terminal. 

For example, when an application needs to switch 
between users, it may do it by identifying the user 
using a logon screen, by PIN codes or passwords, or 
even personalized smart cards, or voice control, for 
example . 

The permission (s) enable the users to access a 
45 resource/invoke functions of the terminal. This refers 

to accessing either some physical resource on the 
receiver, such as a modem or a tuner, the smart card, 
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etc., or an application, such as e-mail, web browsing, 
e- commerce, etc. 

The resource may be, for example, a device, 
function or a process on the receiver, such as a tuner, 
modem, database, plug- in module, cable, software 
module, network interface card, persistent storage, TV 
screen space, memory, CPU, conditional access (CA) 
module, and so forth. 

The API also is adapted to define one or more new 
types of user preferences, and add the new types of 
user preferences to the preferences registry. The new 
user preferences can be defined by a base interface, 
Preference, which is an object that can be added or 
removed from the Pref erenceRegistry . This allows one 
to define new types of user preferences, e.g., by 
extending it the same way as the Language Preference 
extends the base Preference. 

For example, the preferences may include specific 
types of programs (sports, drama, humor, action, etc.). 

The API also is adapted to associate the new types 
of user preferences with the users. 

The API may be independent of an operating system 
and hardware of the terminal. 

A corresponding method is also presented. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows package relationships and 
dependencies in accordance with the present invention. 

FIG. 2 illustrates a user class/interface diagram 
in accordance with the present invention. 

FIG. 3 illustrates a preferences class/interface 
diagram in accordance with the present invention. 

FIG. 4 illustrates a registry class/interface 
diagram in accordance with the present invention. 
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DETAILED DESCRIPTION OP THE INVENTION 
1 . INTRODUCTION 

The present invention provides an Application 
Programming Interface (API) for downloadable broadcast 
applications to manage/access user-related information 
on a Digital Television (DTV) Receiver. 

The invention comprises the following two API 
components: 1) User API; and 2) User Preferences API. 

They can be used together where each user has a 
set of user preferences associated with it, or 
separately where there is a system- level set of 
preferences without a user association. 

A Registry package is also described herein, which 
provides a generic mechanism for registry- type 
constructs . 

2. MODEL DESCRIPTION 

FIG. 1 illustrates an API package in accordance 
with the present invention, namely a User package 110, 
a Preferences package 120, and a Registry package 130. 
These packages are described in the following sections, 
in connection with FIGs 2-4. 

Note that portions of the disclosure were 
generated automatically from Rational Rose(tm) CASE 
tool, developed by Rational Software Corporation, USA. 
The figures use the Rational Rose (tm) depiction of the 
Unified Modeling Language (UML) , which is a language 
for specifying, constructing, visualizing, and 
documenting the artifacts of a software -intensive 
system. A class diagram represents the static 
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structure of a system, and shows a pattern of behaviors 
that the system exhibits. This is accomplished by 
showing the existence of classes and their 
relationships. Each class is represented by a box with 
three sections. The top section lists the class name. 
The middle section denotes a list of attributes, and 
the bottom section denotes a list of operations. 

A solid or dashed line between classes denotes an 
association or dependency. A white diamond tip denotes 
aggregation by reference, while a black diamond tip 
denotes aggregation by value. A triangular arrowhead 
denotes a restricted navigation, e.g., inheritance of 
operation but not of structure. 

Moreover, interfaces and classes begin with an 
uppercase letter, while methods begin with a lowercase 
letter. A class is a template that defines a data 
structure, method and function calls for an object. An 
interface defines a set of methods /function calls that 
can be manipulated by a class. The class provides the 
code for implementing an interface. 

2 . 1 User Package 

FIG. 2 illustrates a user class/interface diagram 
in accordance with the present invention. A main 
UserRegistry interface 210 is the access point for 
getting information about any user. One or more users 
can be associated with each terminal (e.g., DTV 
receiver, set-top box, IRD, TV-enabled PC, etc.) 
Existing users can be retrieved, new ones can be 
created, and the current active user can be set via the 
UserRegistry object 210. The user is represented by the 
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UserProfile object 220., which holds the user's name and 
the user's preferences. The preferences may be that 
the user prefers to view/use certain types of 
television programs (e.g., favorite channels) and/or 
applications, preferred audio language, personal data, 
such age, location (address/ zip code) , credit card 
numbers, etc. The user can be authenticated by 
invoking the implementation-neutral method 
authenticate () , which may invoke the particular 
mechanism of authenticating a user, such as Personal 
Identification Number (PIN) codes, passwords, etc. 
Users are associated with permissions which are 
internally used to enforce a security policy. 
Therefore, new permissions can be granted to each user. 
The permissions are implementation- specific since they 
are internal to the terminal. 

2.2 Preferences Package 

FIG. 3 illustrates a preferences class/interface 
diagram in accordance with the present invention. 

The preference package 120 serves two primary 
purposes: to hold system-wide preferences and to hold 
user- specif ic preferences. 

A system-wide preference is anything that applies 
to all users. For example, English may be a system 
wide preferred language which applies to all user 
unless they override it with their own user-specific 
preference (e.g., Spanish). 

When the preference is used in the system-wide 
sense, the access to it is provided via the 
PreferenceRegistry 310 obtained from the 
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Regis try Factory 430 {FIG . 4) . The user-specific 
preferences can be obtained directly from the user 
(UeerProfile 220) . 

Any new preferences or settings must derive from 
the abstract Preference interface 330, which provides 
the listener mechanism and access to the unique 
preference name. The derived class/interface can 
provide any methods, behavior and data structures 
needed to describe the specific preference or settings 
object . 

Each application can register as a listener (using 
the addPropertyChangeListener {) method) to a specific 
preference and be notified via the propertyChange ( ) 
method it must implement . 

Properties are uniquely identified by their names. 
If an application tries to store a Property with a 
duplicate name, the Pre ferenceAl ready Exists Exception 
390 will be thrown. If the application does not have 
enough privileges to perform any of the 
Pref erenceRegistry 310 methods, the 
AccessDeniedException 385 will be thrown. 

Proper tyChangeEvent 3 50 is defined in the standard 
Java packages (JDK 1.2) . Also, the notations "from 
security" in class 385, and "from beans" refer to 
classes ("Security" and "Beans", respectively) that are 
defined in JDK 1.2. 

2.3 Registry Package 

FIG. 4 illustrates a registry class/interface 
diagram in accordance with the present invention. 
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The Registry package 13 0 provides a basic 
mechanism to construct a Registry object of any kind. 
The Registry interface 410 is a base interface which is 
extended by all specific Registries, such as the 
UserRegistry 210 or the Pref erenceRegistry 310. 

A RegistryListener interface 44 0 and a 
RegistryChangeEvent interface 250 are associated with 
this package. The listener interface 440 is used by 
any object that wants to be notified of any changes in 
the Registry 410. Changes are considered those that 
affect the Registry 410 itself (not necessarily the 
individual elements in the registry) , such as adding or 
removing elements to/ from the Registry. The 
RegistryChangeEvent 250 is an abstract class which is 
extended by the specific registry events. 

Since most of the API is defined in terms of Java 
Interfaces, the RegistryFactory 430 is a class that 
hides the actual object construction implementation. 

The notation "from util" in the EventObject class 
415 refers to a class "Util" that is defined in JDK 
1.2 . 

The notation "from resource" in the 
ResourceRegistry interface 480 refers to a class 
"Resource" that is discussed in commonly- assigned PCT 

Patent Application No. , filed October 7, 

1999, and entitled "Application Programming Interface 
(API) For Accessing And Managing Resources In A Digital 
Television Receiver." 

The notation "from application" in the 
ApplicationRegistry interface 490 refers to a class 
"Application" that is discussed in commonly- assigned 
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PCT Patent Application No. , filed October 

7, 1999, and entitled "Software Application Lifecycle 
And Management For Broadcast Applications." 

3. CLASS AND INTERFACE DESCRIPTION 

The following sections provide the details of each 
class, interface and its methods. 

3.1 User Package 

This package 110 provides classes and interfaces 
necessary for user management functions. 

3.1.1 UserEegistry 

UserRegistry interface 210 provides access to all 
users defined on the system. It is derived from 
Registry 130. 

Public Operations: 

createUser {name : String) : UserProfile 

This method will create a new user of the 
specified name. 

Public operations are those methods that may be 
called and used by other objects since they are visible 
outside of the object (e.g., class). In contrast, 
private operations are visible only to the class 
itself . 

getCurrentUser () : UserProfile 

This method returns the user who is currently 
registered as the active user. 
getUserNames () : String [] 

This method returns a list of all known users in 
the registry. 
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setCurrentUser (newUser : String) : UserProfile 

This method defines a new current user. The 
implementation may prompt the user for a password or 
some other method of authentication. 

getUser (name i String) : UserProfile 

This method returns a UserProfile object of the 
specified name. 

3.1.2 UserProfile 

This interface 220 represents a container of a 
single user information, such as settings and 
preferences, billing info, etc. it is derived from 
UserPermissions 23 0. 

Publ i c Operat i ons : 

get Name ( ) : String 

Returns the name of this user. 
getPref erences () : Pref erenceRegistry 

This method returns this user's 
Pref erenceRegistry . All operations performed on the 
returned list of preferences will be reflected in this 

UserProfile . 

authenticate () : boolean 

This method is called to authenticate a user. It 
invokes an implementat ion- specif ic mechanism for user 
authentication. It may use a user dialog to ask for a 
password or PIN, or other authentication mechanisms. 

Returns TRUE if authentication succeeded; FALSE 
otherwise . 

grantPennission (newpennies ion : String) : void 

This method is called to add a new permission to 
the user. See UserPermissions. 



WO 00/30345 



16 



PCT/US99/23346 



3.1.3 OserPermissions 

This interface 23 0 defines a list of user 
permissions that can be granted to a user. 
Public Attributes: 
IPPV : String - "IPPV Purchase" 
RATING : String = "Rating Override" 

3.1.4 UserRegis tryEven t 260 

Derived from RegistryChangeEvent 250. 

Public Operations: 

getUserName () : java. lang. String 

This msthcd returns the User "ams of the User that 
caused this event. 

3.1.5 Us erChangeCaus e 

This interface 24 0 defines possible causes for the 
UserRegistryEvent 260. 
Public Attributes: 
USER_ADDED j short » 1 
USER_REMOVED : short = 2 
NEW_CURRENT_USER : short = 3 

3.2 Preferences Package 

This package 120 defines a set of interfaces and 
classes which provide a mechanism to define a set of 
preferences, either at the system level or at the user 
level . 

3.2.1 Pref erenceAl ready Exist sExcept ion 
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This exception 3 90 signals that a preference of 
the same name is already present in the registry and 
cannot be inserted (added) again. It is derived from 
Exception, which is in the JDK 1.2 core Java packages - 
j ava . lang . Except ion . 

3.2.2 Pref erenceRegis try 

This interface 310 represents a registry of all 
settings and preferences that can be shared by multiple 
applications. It is derived from Registry 130. 

Publ i c Operat ions : 

getPref erence (pref erenceName : String) : 
org t atsc • preferences t Preference 

This method returns the preference of the 
specified name, or null if the name is unknown to the 
registry. 

addPref erence (aPref erence : 
org. atsc. preferences. Pref erence) : void 

This method allows an application to insert a new 
preference object into the registry. The new 
preference must be of a unique name. 

reraovePref erence (pref erenceName 2 String) : void 

This method allows an application to remove a 
preference object from the registry. 

listPref erences () ; 
org . atsc . preferences . Preference [] 

This method returns a list of all Preferences 
currently stored in the registry. 



3.2.3 Pref erredLanguage 
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This interface 340 is an example of a language 
preference interface. An ordered list of ISO 639.2 
alpha -3 strings is used. The first language in the 
list is the most desirable language. It is derived 
from the Preference interface 330. 

Public Operations: 

getLanguage () i String [] 

This method returns an ordered list (most 
desirable first) of three letter ISO language codes. 
setLanguage (value List : String [] ) : void 

This method allows an application to change the 
language preference. It returns the new list. 

3.2.4 RatingPref erence 

This interface 335 represents a parental rating 
preference based, e.g., on age. It is derived from the 
Preference interface 330. 

Public Operations : 

getRatingCeiling () : String 

This method returns the maximum rating value 
allowed for watching. 

setRatingCeiling (aValue : String) ; String 

This method allows an application to change the 
rating ceiling. It returns the new rating level. 

3.2.5 Preference 

This is a top-level interface 330 which is common 
for all pref erence/settings subinterf aces . It supports 
the listener model and provides the preference name. 
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This interface can be extended to support specific 
preferences with specific access methods. It is 
derived from Pre f erenceName s 320. 

Public Operations: 

addPropertyChangeListener (aListener : 
Proper tyChangeliistener) : void 

This method allows applications interested in 
changes to this preference to register for preference 
change events. 

removePropertyChangeListener (aListener : 
Proper tyChangeListener) : void 

This method allows a preference change listener to 

- . r — J *- C «1 -P -C— 1 ~ —4- ~ C 1 i _4 

i.CUiV vc J-UOG-ti- l^VIII L.UC A AOL. Ui ixoucucia . 

getPref erenceName () : String 

This method returns a unique preference name. 

3.2.6 Pre f erenceName s 

This interface 320 contains a list of predefined 
preference names. 

Public Attributes: 

SIMPLE_RATING : String « "Simple Rating" 
LANGUAGE : String = "Language 11 

3*2.7 Pref erenceRegistryEvent 

This event 360 informs the RegistryListener 44 0 
about changes in the Pref erenceRegistry 310. It is 
derived from Reg is tryChange Event 250. 

Public Operations: 

getPref erence () : org. atsc .preferences. Preference 

Returns the preference that has changed in the 
repository. This change concerns the repository, such 
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as adding or removing a Preference from the 
PreferenceRegistry 310, not a change in the value of 
the Preference. 

3.2.8 Pref arenceChangeCause 

This interface 345 defines reasons for a 
Pref erenceRegistryEvent 360. 
Public Attributes: 
PREFERENCE_ADDED : short = 1 
PREFERENCE_REMOVET : short « 2 

3.3 Registry Package 

This package 130 provides a set of supporting and 
utility classes and interfaces used by other packages. 

3.3.1 Registry 

This interface 410 provides a common root to all 
specialized registry interfaces, such 
ApplicationRegistry 490, ResourceRegistry 480, 
PreferenceRegistry 310, etc. It is provided so that 
the RegistryFactory 430 can return a base type. 

A "base type" is known from the field of object- 
oriented programming. To illustrate, one can define a 
class with a set of functions (methods) and internal 
variables (e.g., a class "Fruit" which represents fruit 
and its basic characteristics) . One can specialize it 
by defining a new class, "Apple", which inherits 
everything from the class "Fruit", and adds new 
functions that are applicable only to Apples but not to 
Fruit in general. "Fruit" is then referred to as a 
"base class" or a "base type." 
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The Registry interface 410 is derived from 
Registry-Type 405. 

Public Operations: 
getRegistryType () : String 

Called to determine the type of registry 
implemented by the object returned by the 
RegistryFatory 's (430) method getRegistry ( ) . 

addRegistryListener (listener: Regis tryListeaer) : 

Called to register for events generated by the 
Registry 410. 

removeRegistryListener (listener : 
Regis try Listener) : 

Called to de- register for events generated by the 
Registry 410. 

3.3.2 RegistryFactory 

This class 430 provides a mechanism to create 
objects that implement specific Registry interfaces, 
such as the ApplicationRegistry 490. This class is 
modeled after the Factory Method design pattern, which, 
as is known from the field of object-oriented 
programming, is a methodology and structure for solving 
a problem. 

Public Operations: 

RegistryFactory () : 

Constructor 

getRegistry ( regie try Name : String) : 
org . atsc . registry . Registry 

Returns an instance of an object which implements 
the specified registry interface. Returns null when 
specified registry does not exist or cannot be created. 
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The type of the returned object will be one of the 
derived Registry types, such as the ApplicationRegistry 
490. 

3.3.3 RegistryType 

This interface 405 defines names for different 
registry types, such as an application registry, etc. 
Public Attributes: 

APPL I CATION_REG I STRY : String a "Application 
Registry* 1 

RES OURCE_REGI STRY : String = "Resource Registry" 
PRE FERENCEREGI STRY : String = "Preference 
Registry 11 

USER_REGISTRY : String ■ "User Registry" 

3.3.4 Regis tryListener 

This interface 440 allows an object to listen to 
changes made to the Registry 410. 
Public Operations: 

regis tryChange () : ApplicationRegistry Event 

This method of all registered 
ApplicationRegistryListeners is called by the 
ApplicationRegistry object 4 90 when an 
ApplicaionRegistryEvent is fired (emitted) . 

3.3.5 Regis tryChangoEvent 

This event 250 is a generic registry change event 
that is extended by all specific registries (such as 
ApplicationRegistry 490, etc.) to provide specific 
information about the change. It is derived from 
EventObject 415. 
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Publ i c Opera t i ons : 

getRegietryType () : java.lang. String 

Returns the type of a registry that this event is 
associated with. 

15 

5 getCause () : short 

Returns the cause of the RegistryChangeEvent 250. 
Each derived event will define a set of causes 
appropriate for the registry it represents. 

20 

Accordingly, it can be seen that the present 



10 invention provides an API for applications to 

manage/access user- related information on a Digital 

^ Television ( DTV) Receiver /Terminal . The APT provides a 

multi-user environment, and a registry for preferences 
which can be associated with an individual user or be 
15 common to all users. A set of permissions is 

30 associated with each user, or at least with a default 

user. The permission may provide, for example, a 
parental control /rating ceiling or permission to buy 
Impulse Pay Per View (IPPV) programs, or engage in e- 

35 20 commerce transactions (e.g., purchase goods or services 

via the television) . The invention also supports a 
mechanism where some applications can, and some cannot, 
access the preferences based on a security policy. 

40 This means that the user may allow only specified 

25 trusted applications to access his/her credit card 

number* but not others, for example, for an e-commerce 
application. 

45 Although the invention has been described in 

connection with various specific embodiments, those 
30 skilled in the art will appreciate that numerous 
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adaptations and modifications may be made thereto 
without departing from the spirit and scope of the 
invention as set forth in the claims. 

For example, while various syntax elements have 
been discussed herein, note that they are examples 
only, and any syntax may be used. 

Moreover, the invention is suitable for use with 
virtually any type of network, including cable or 
satellite television broadband communication networks, 
local area networks (LANs), metropolitan area networks 
(MANs) , wide area networks (WANs) , internets, 
intranets, and the Internet, or combinations thereof. 

Additionally, known computer hardware, firmware 
and/or software techniques may be used to implement the 
invention. 
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What is claimed is: 

1. A television set- top terminal, comprising: 

a computer readable medium having computer program 
code means; and 

means for executing said computer program code 
means to implement an Application Programming Interface 
(API) for accessing user-related information at the 
terminal , wherein : 

the API provides: (a) a user registry of a 
plurality of users of the terminal, (b) a preferences 
registry of preferences of the users, and (c) 



>~> en i 1 ' 1 ) o til 



least one application that is provided at the terminal. 

2. The terminal of claim 1, wherein: 
the API provides a security policy to allow only 
specified applications to access the preferences 
registry. 

35 3. The terminal of claim 2, wherein: 

the security policy is user-controlled. 

4. The terminal of claim 1, wherein: 

40 the permission (s) are associated with each user. 

5. The terminal of claim 1, wherein: 

the permission (s) are associated with a default 

45 user. 

6. The terminal of claim 1, wherein: 
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the at least one application is responsive to the 
user preferences . 

7. The terminal of claim 1, wherein: 

the permission (s) control the users' access to a 
plurality of applications that are provided at the 
terminal . 

8. The terminal of claim 1, wherein: 

the preferences include a language preference. 

9. The terminal of claim 1, wherein: 
the preferences include a ratings ceiling 

preference . 

10. The terminal of claim 1, wherein: 
said user preferences include system-wide 

preferences . 

11. The terminal of claim 1, wherein: 
said user preferences include user-specific 

preferences . 

12. The terminal of claim 1, wherein: 

the user registry registers a new user of the 
terminal « 

13. The terminal of claim 1, wherein: 

the user registry identifies a current user of the 
terminal . 
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14. The terminal of claim 1, wherein: 

the user registry removes a former user of the 
terminal . 

15. The terminal of claim 1, wherein: 

the permission (s) enable the users to access a 
resource of the terminal . 

16. The terminal of claim l, wherein: 

the API is adapted to define at least one new type 
of user preference, and add the new type of user 
preference to the preferences registry. 

17. The terminal of claim 16, wherein: 

the API is adapted to associate the new type of 
user preference with the users. 



18. The terminal of claim 1, wherein: 

the API disallows access to user preferences by an 
application that does not have the required 
35 permission (s) . 

19. A method for implementing a software 
architecture for a television set-top terminal, 

40 comprising the steps of: 

providing a computer readable medium having 
computer program code means; and 

executing said computer program code means to 
45 implement an Application Programming Interface (API) to 

provide : 

(a) a user registry of a plurality of users of the 

50 
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terminal, (b) a preferences registry of preferences of 
the users, and (c) permission (s) for controlling the 
users' access to at least one application that is 
provided at the terminal . 

20. The method of claim 19, wherein: 

the API provides a security policy to allow only 

specified applications to access the preferences 

registry . 
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